Search
本篇文章要介紹的是 2021 年熱門的日誌視覺化分析工具，作者於本篇文章列出 8 種不同的工具，分別是
1. Logiq.ai (2019 創立)
2. Datadog (2010 創立)
4. Dynatrace (2005 創立)
5. Logz.io (2014 創立)
6. Graylog (2009 創立)
7. Google Cloud Logging
8. Scalyr (2011 創立)
9. LOGalyze (開源專案，但是官網連 HTTPS 都沒有....)
作者列出的基本上都是商業解決方案，要使用開源方案還是商業解決方案一直以來都沒有絕對的答案，畢竟一個解決方案除了功能完整性之外，技術支援也是非常重要的一環。
好奇上述的解決方案大家有沒有相關使用經驗？
https://medium.com/nerd-for-tech/top-log-visualization-tools-in-2021-fa0a2d897ad1
因為看到這一篇文，讓我想要請教我很佩服，也曾經待過 LinkedIn 的實戰強者 Ian Tsai
，他的洞見與補充，真的是滿滿的功力跟學問。
經過他同意之後，想分享給更多人一起學習交流。相信可以對很多強者、想變強的強者、老闆、技術管理者帶來一些 AHA 與幫助。
原討論串：https://www.facebook.com/1069344389/posts/10220464611619871/?d=n
原討論串的文章：https://mp.weixin.qq.com/s/NhES8FHIhyfCxaPiM508EQ
—
以下來自 Ian:
1)
這篇文章的核心前提，是『重寫』
只有一開始就把很多東西做好，相對獨立且沒有過去包袱的專案才能這樣搞出十倍速，比如Voyager Mobile App
其他division 的產品與系統，有太多跟舊系統交雜在一起而動不了的，就不可能達到他講的3X3，因為有需要在那些系統上開發，就是會很慢
然後他還有一個假設就是做這個專案的從頭都是某個人做中間不換人，LinkedIn的平均工程師年資就是2.5年，所以，他在專案開始啟動的那兩年可能是可以的，兩年之後就很難說了，因為新加入的人也不可能可以這麼快入手，起碼以我觀察LinkedIn內部做Knowledge transfer 就是沒那麼快(但LinkedIn 可能是算快的)
針對這一點，現在需要搞軟體開發的公司，都應該要有一個Tools Team，而這個team 其中一項最重要的業務，就是開發維護一套公司內部使用的KMS系統，而這套系統的核心必定是一個Omni Search Engine，能夠跨越多個異質CMS 平台、EMail、IM、VCS 把所有的自然語言與程式語言的內容都能集成在搜尋結果(Google search result + web IDE)中呈現，沒有這個，只靠現成的外部工具提供的功能，找來的人平均會需要至少兩到三倍的時間才能進入情況(LinkedIn 有這個，超好用！)
最後一個需要的是高度客製化的CI系統，這種平台的CI系統不能有太多人為介入得要全自動，整個流水線過程中發生的任何錯誤，都能在第一時間全自動的通知『真正的負責人』，包含log、request context, call tree graph都提供，才能讓開發人員不會害怕系統出錯，而不必在開發階段搞很多很複雜的E2E Test
至於測試，這段老實說就是設計架構切割是不是有真的切在對的邊界上，一旦切錯，測試不是很難寫就是寫一堆沒用的，而且我在LinkedIn後期，還是有產品線為了衝Craftsmanship 指標搞出要求工程師 code coverage 90%的要求
我覺得對於backend，真正重要的是distributed Log management system，還有像是Datadog 這樣快速方便的 System Monitoring 服務，在寫程式的時候把這些一開始就根據業務邏輯規劃進去，然後確保觀察得到的與預測符合，這些在現在都比拼測試重要，因為Microservices 之後，對於很上游的Upstream 服務，要對每個Downstream Service 一開始就搞出範圍適當的defensive programming 是很麻煩的
這其實也是一個後端架構上的硬需求，也就是每一個Module 在software stack 上 ，對於他使用的任何Downstream Service 怎麼做Async + Failover + Timeout + Circuit Breaker + Monitoring & Instrumentation + Graceful Degradation + Logging & Alerting ... 都要有方案且預先做出來，不然想要App backend developer 在後端一邊搞Home Made solution 一邊還要拼出3X3 的效率也是不可能的。
2)
其實好的產品開發工程團隊，一定要持續規劃有人去conclude 系統中的共通需求，透過共識討論找到合適的解決方案，然後也一定要有農閒期，好讓這種共識得出的艱難改造有喘息的機會上線
這個佔總體開發量大概至少得要15% ~ 20%，也就是團隊如果有10個專職開發者，那至少要有一個名額(不同專長的人輪流)負責幫大家把刀磨利、把工具保養好
不然熵會把系統吃掉的。
Joey: 完全認同，全局優化，避免重工、多頭馬車、穀倉、無法相容異質系統的影響，永遠都在熵的影響下消耗掉所有產能。
就是那個「壯士斷腕」的決心，要把有能力的人拉出來搞全局的、長期的健壯性，很多公司跨不過去，除非已經有一個起家厝在養家了。
Ian:
問題就是方形的車輪滾不遠，做產品的團隊經營超過一年後還沒有建立閒置產能，那第二年就會在不同的專業領域接連出現技術落伍的現象，而好的工程師都是很敏感的，當老闆持續消耗自己的職業壽命賺錢或求生的時候，他自然會考慮繼續待著機會成本是否划算
這種考慮講個幾次，越是有野心、有衝勁、early adopter 類型的人才就會越早流失，而這是最糟糕的，因為這種人才是幫助公司導入新技術、保持團隊知識領先的關鍵火星塞，所以這種人被天擇掉了之後，剩下來的人不論在價值觀、還是行為慣性上都會更保守、更抗拒變化
這一但超過一個閥值(或者說事件地平線)就不可能回來，這間公司不論當時訂單多少、市場再大都要走入平庸了
當然，如果他家大業大而且上層還能持續透過併購招募新血，那或許還能透過慣性再小衝一段，但都是減緩衰退續命而已。
Serilog Sink that sends log events to Datadog https://www.datadoghq.com/ - GitHub - DataDog/serilog-sinks-datadog-logs: Serilog Sink that sends log events ... ... <看更多>
... <看更多>
datadog log 在 DataDog Logs: using search, filter and sort operations. 的推薦與評價
A demonstration of the DataDog Logs product. With this video you'll see how to search through logs (specifically, from nginx) and perform ... ... <看更多>